“数据中台”是一个伪概念吗？｜腾研识者
编者按
把2019年称为“中台元年”似乎并不为过，各种中台概念被生造出来，鱼龙混杂；许多旧的架构也摇身一变，被包装成各色中台……这不禁让我们深深怀疑——中台这东西，到底靠谱吗？
这篇文章讲的是数据中台。腾研识者火雪挺特别擅长用通俗的生活例子诠释复杂的概念。爱好健身的他之前比较了游泳健身与人工智能的共性，在这篇文章中，他将用小渔村的故事来介绍数据中台的来龙去脉，并将探讨一个直击灵魂的问题：不做中台，会死吗？
文章大纲：
1. 从“小渔村的故事”看数据中台
2. 数据中台的三个能力层级
从“小渔村的故事”看数据中台
将拗口的概念先放在一边，为了帮助大家更好地理解“数据中台”以及与之相关的关键环节，我想讲一个故事——《小渔村的改革自强之路》，故事是这样的：
1. 海边有个小渔村，村民以捕鱼为生，突然有一天，村长决定改革开放，搞市场经济，于是他把村子沿岸的海给围了起来，不允许其他村子的人到这里来捕鱼，确定了本村这个“大鱼塘”的范围。
2. 其次，他把整个鱼塘的捕捞权承包给了村子里有意愿搞市场经济的人家，允许他们拿村里的海鲜作为资源去进行贸易，所得收入归自有，每年村子向他们收取一定的使用费用。现在大家可以把这个“鱼”想象成“数据”。
3. 由于每位村民捕鱼技巧和喜好不同，所以他们从大鱼塘捞上来的海鲜品种也不一样，于是最原始的业务数据积累就产生了。
4. 村民们把海鲜批发给远近不同的海鲜市场，由于都是自己配送，运输条件不足，常常造成了海鲜的腐烂，货损货差严重，这就是业务数据多源异构的问题，质量和时效参差不齐。
5. 后来村民和村长商量，每户人家把大鱼塘都划出一块小鱼塘来，按自己的喜好进行捕捞和养殖，就这样垂直的业务系统数据源产生了。
6. 不同的海鲜市场对不同村民家的海鲜品类有不同的需求，在物流运输上没有统一规划造成了浪费。因此，村长决定整合村子里的闲杂人、车资源组成一支运输队，统一规划和物流，于是数据服务总线诞生了。
7. 整个村子生意越做越不错，引来了很多临近的村子前来主动采购，于是“数据需求”开始呈现出卖方市场的迹象。因此村长又决定在村子边建立起海边海鲜市场做销售批发，并指定了一位市场管理员，他需要洞悉市场需求，按需带头向大家采购不同海鲜品类。这样不仅保证了供货是市场所需的，质量经过统一审查的，再加上之前的物流运输队，可以做到时效有统一保障，大家的货损货差都少了，收入和效率都提高了，因此大家都很开心，是个多赢的局面。这可以理解为数据平台成立了。
8. 稳定中求发展，村长决定开展一些高增值的服务，例如海鲜半成品，就是海鲜经过去除内脏、清洗、甚至是腌制等工序，然后真空包装，可以直接送到超市、饭店，甚至是临近的村民家里，客户直接下锅就可以做菜了。这个过程就是数据清洗、数据ETL的过程，体现了数据服务向多样化、终端化（业务化）迈进。
9. 村长又发现，由于客户对于海鲜的做法不同，有些人并不太在意新鲜程度，因此决定建立一个大型冷库，把那些对新鲜程度要求不高的海鲜品冷冻或冷藏其中，每天定时向目标客户进行配送，这样就减少了由于打捞时间不同，或者天气原因导致的配送时间的不可控，对整体物流规划也是一个利好。这就是我们常说的数据仓库的构建。
10. 村长觉得是时候开始做零售了，毕竟零售的毛利更高。于是村长又指定了一系列外派人员，根据所知临近村庄的不同口味，带着不同的海鲜品种去那里开海鲜超市，直接面对最终消费者。于是数据集市也有了。
11. 村子的生意越做越大，食品管理局开始入驻，要对所有海鲜品进行质量的监测。不但要检测，还要能回溯，一旦某一批的鱼坏了，村长和小组长们要知道这个鱼是从哪个鱼塘捕捞的，是由谁捕捞的，这样就能去分析原因，对相关人员进行教育指导。这就是数据质量管理、元数据管理，数据血缘分析等作用。
12. 不仅如此，税务局的人也常来了，对村子和个人的所得税进行审计工作，称之为数据资产分析。而且为了方便管理，村长要求村民们至少能会写、会读关于海鲜品类的文字和知识，而且用统一的名称和语言。这就是数据字典和数据标准化的作用。
13. 村子发达出名之后，越来越多的人来到这里，于是这些人的衣食住行就既成了问题又成了商机。一开始他们去村民的家里吃“农家乐”，村民提供固定的菜单和住宿标准，就像提供了固定的“数据产品”。同时呢，也有些店家很聪明，直接提供给客人一张渔网、一个炉子、一张桌子和各类香料配料，客人自己按喜好去捕捞和烹饪，让喜欢自己动手的客人非常满足。这就是我们讲的，数据中台的平台能力服务和基础算力服务等。
14. 村长也集合精干之力，建设起了村里的第一个豪华五星级酒店，酒店不仅有海底观景房、售卖各类鱼骨装饰品，而且还有相当丰富的海鲜菜单，从前菜到甜点都由海鲜制成，整一个“海鲜全席”，这是我们说的灵活和多样性的数据服务。由于费用不菲，这部分服务只能由高净值的VIP客户享用。这就是我们说数据中台团队应整合数据、平台、算力等能力，瞄准最关键的20%核心业务需求，解决组织内80%的核心业务问题。
15. 再好吃的东西，吃多了就会厌。村长临机一动又来一招，就是允许和鼓励各村民家在自己的小鱼塘里面搞一些交叉养殖的实验，希望可以培养出更多的海鲜新品种来，这就是我们通常说的机器训练平台或算法训练平台的作用，挖掘更多数据的价值。
16. 村长由于带领整个村子奔小康，被评为时代改革先锋，村子也声名远扬。不仅是汽车、火车和船只都驶来交流经验，而且贸易更加频繁、市场成长很快，因此村子里铺设了符合国家标准的铁轨、修建了车站，还兴建了国际港口，符合万吨轮级别的航运要求。这就是中台提供标准的数据接口，不仅执行数据接入，还提供数据订阅、数据消费的作用。
数据中台的三个能力层级
听完“小渔村的故事”，相信你会对数据中台的角色和作用有初步的了解。如果说数据中台的建设有一个目标的话，那就是整合数据、技术、算力和平台级别的能力来解决业务上的问题，其建设原则应该是先立后破、循序渐进、升级融合、风险可控，永远要考虑的一个重点平衡中台的资源投入和对业务带来的价值产出。
这个价值能力模型如下：
基于此，我认为数据中台应当提供三个层次的能力：
1. 在中台能力及资源充足的情况下（包括业务知识、技术能力、人才积累），提供数据产品、数据服务。
一般而言，数据应用是上层的概念，让用户去使用的东西，而数据产品和服务则是两种不同的应用。产品提供预定义好的标准化功能，优点是使用简单、易于维护，缺点就是缺乏个性化、定制化的能力；而服务则要灵活、多变的多，当然成本和实现周期也会因人而异。
这些数据产品及服务有其共性的一面，当然也由因行业及场景的不同，有多样性的一面。将其共性抽象一下，无外乎包含以下几类：
l 决策支持类：主题报表（月度/季度/年度/专题）、舆情监控、热点发现、大屏数据可视化展示等
l 数据分析类：交互式商业智能、OLAP分析、数据挖掘、数据驱动的机器学习等
l 数据检索类：全文检索、日志分析、数据血缘分析、数据地图等
l 数据共享开放类：实时数据订阅、离线数据接触、数据API接出
而多样性的一面每个行业都会不一样，常见的有:
l 用户相关：用户画像服务、用户成长/流失分析及预测、点击率预测、智能推荐等
l 市场相关：数据服务于搜索引擎、数据服务于推荐引擎、热点发现、舆情监控等
l 制造生产相关：预测性维护、生产过程实时数据监控、数字孪生等
当提供第一种能力的时候，数据中台的应用和管理都会有中台团队负责搭建和运维，此时管理和应用都是集中的。对于构建者、管理者要注意的是，我们要紧盯所有业务中那最重要的、具有战略性的20%，集中资源和精力来为其提供数据产品或服务，因为它们往往代表着80%的核心业务价值。当然为了做到这一点，与各业务线同僚的有效沟通和大格局的审时度势能力是必不可少的。
2. 在中台业务能力及人力资源不充分、但体系相对成熟的情况下（包括数据体系、技术体系），提供平台级别的能力，包括数据平台能力、技术平台能力、建模平台能力等，甚至是数据本身。
企业建设项目有两个很重要但通常会被忽略的因素：人才和知识的累积。当前台对市场、用户的感知越来越敏锐的时候，就会产生越来越多、越来越快的数据消费需求，因此这种情况下，中台无法参与并满足前端的所有业务需求，一种新的能力需要被孕育出来，那就是前端业务在处理数据、使用数据的时候，对于后端来讲是“无感知”但“可管理”的，这个时候就需要一个中间层，这个中间层帮助业务需求与技术支撑的“解耦”，也就是这个中台，中台的价值也就体现了出来。这里有三点需要说明的：
l 无感知：业务侧产生数据处理、计算、存储和对自身数据消费的需求，不需要向中台进行预先申请，也不需要中台技术人员做相应的技术操作，业务人员自己就可以通过简单的配置来完成这个数据方面的需求，包括数据的接入、存储、简单的计算，甚至是简单的维度分析等，还有自助式的数据订阅、数据接出等需求。
l 可管理：虽然中台人员不用参与每一个业务的数据需求，但这些动作对于中台都是可见的。从资源上来讲，可以对较耗资源、异常的数据任务进行限流或中止，对较大、异常的库表进行隔离或优化；从数据上来讲，凡事接入的业务数据，中台人员可以通过平台操作进一步将对中台有价值的数据落地、入库，有必要的话接入中台的数据清洗、加工流程、调控流程，使之成为可预见的资产，并使其进一步与其他业务数据融合，构建高价值密度的数据仓库，在库内消灭数据烟囱，产生更大的数据整合性价值，为提供面向业务用户的数据集市、自助式决策分析、自助式数据分析打下基础。
l 解耦：以前当我们可以提供较完备的数据仓库/集市的时候，产生了自助式的BI分析，解决了业务人员需求报表，但技术人员来不及做的尴尬；现在我们也理应打造这样的中台，通过这样的能力，给业务人员提供自助式的、一站式的、从产生数据到产生价值的完整通路。
在第二种情况下，数据中台应当提供的是：
l 数据平台的能力：包括全域的数据采集能力（多业务、多终端、多形态）、自助式的数据接入、存储和消费工具的开放；自动的建库、建表、分区、消息Topic建立能力，简单的自助式数据分析、数据检索和数据审计能力，事件及日志的查询能力；数据清洗及任务调度工具的开放；数据资产分析能力的开放。
l 技术平台的能力：现在越来越多的业务系统由于时效性及数据处理的要求，也会用到消息队列和NoSQL的能力，特别是有海量数据快速检索类的需求时，那中台就应该为中台相关的系统提供这种技术组件来满足需要，像kafka这种可以作为业务系统之间的消息分发通道或发布队列，HBase作为KV存储提供业务系统的查询能力等。
l 建模平台的能力：或者应该说是提供基于数据，进行统计机器学习建模的能力，包括了自助式模型训练、算法引入、模型发布与服务管理的能力
l 数据本身：通常来讲，除了算法训练平台或数据对账审计可能需要原始数据之外，大多数情况下对数据的需求，其实是对清洗过后、价值密度较高的数据集的需求，也就要求中台人员构建合理且鲁棒性高的数据仓库、数据主题库等，构建高聚集、高集计、高针对性的数据集市等，以此为基础提供给业务用户进行分析与应用。有时候对于特定的应用，例如搜索应用、推荐应用、热点应用等，我们还需要构建特定的离线数据集或实时数据流，在特定的频率下（分钟/小时）以特定的方式（消息队列/实时缓存/API）为其供数，这也是数据服务必不可少的一种。为了能够提供这种能力，通常我们需要在数据清洗和转换的过程中大费周章，结合业务知识发掘数据海洋里的“海底石油”并构建石油钻井平台而取之有道。这对数据中台的从业人员也提出了一定的要求。
可以说，当提供第二种能力的时候，数据中台的应用是分散的，管理是集中的。
3. 在中台人力资源和对业务领域知识理解不充分，平台级别能力也无法满足要求的情况下，作为算力基础平台提供服务。
都说数据为王，但人们常忽略另一个事实，那就是在实操过程中，这些数据放哪？放多久？要花多少钱？这里的致命要素就是：服务器。实际的企业环境、特别是传统企业环境，不夸张的说，谁真实地掌控着服务器的管理权和使用权，谁就是“挟天子以令诸侯”。
服务器是真金白银的硬性成本支出，涉及到各个部门每年预算的使用；其次服务器的变动涉及到基础环境的问题、包括机房、水、电、网络、安全等等，所以通常不轻易调整，这个调整包括扩容和释放。而且，服务器代表着切切实实的算力，CPU的、GPU的，这个算力可以用在AI、大数据、也可以用在业务系统、安全系统等。所以通常建设数据中台，在不复杂或无特殊情况下，采购的服务器资源也会有数据中台来控制和管理，于是就有了分配算力的权柄，我们说这是数据中台作为一个算力基础平台的能力。这里又有两层意思：
1. 纯粹的算力平台。用户借助数据中台所拥有服务器的CPU/内存/硬盘等资源来进行自己的业务活动，可以是实验性的数据分析，某些出库订阅任务，甚至和数据没有关系，只是业务程序需要的算力支持。
2. 算力和大数据技术的平台。除开数据应用型的系统，例如用户画像、推荐系统、搜索系统等——它们原来就需要使用到大数据计算的技术组件和大量的计算资源——越来越多的业务相关型系统，例如日志查询、事务监控等系统也会借助大数据的技术组件和相对应的计算资源来确保查询、监控的全量性、时效性，此时这些系统就必须依附在数据中台的算力和技术支撑上，来完成系统里某一个或多个重要的计算或缓存功能。这有点类似于第二层能力中的技术平台能力，但不同点在于，首先这里更看重算力、通常是和中台无关的业务系统，其次中台人员不参与技术组件的部署、配置和开发。
当提供第三种能力的时候，数据中台的人力投入应该是最低的，但需要进行资源的日常监控和任务管理。
前面阐述了个人认为的数据中台“理论上”应该提供的三种不同层面的能力，现在以一张图作为总结，作为“理论上”的数据中台所必要的功能要素示例：
说了那么多，现在我们需要冷静地问一下自己，“不做中台会死吗？”
简短的回答是“不会”。要知道，数据中台一个很重要的部分是数据的融合，并用数据产生的价值去支撑业务。我们要问自己的是：一，能不能做融合；二，融合后对业务有没有支撑作用。
第一，数据融合的前提是融合汇聚之后的数据是有价值的，而有价值的表现要么是可以更完整地刻画你的用户，帮助你去卖东西；要么是可以更完整地刻画你的业务流程，帮助你去做运营；要么是可以更完整地刻画你的经营状态，帮助你去拍板决策；因此其有价值的前提就要求你的业务具备一定的相关性、连续性。如果你同时开了一家汽修店和一家菜市场，你要将两者的用户数据做融合是没有意义的，业务不具备相关和连续性，无论是频率、客单价和受众都差了许多；但如果你同时开了一家金店卖黄金和一家菜市场，那或许还有融合的意义，毕竟大妈们买完菜去金店逛一圈囤个货还是有相关和连续性的。所以业务的相关性是指空间上的，业务的连续性是指时间上的，离开太远的业务，或者时间差别太大的业务，并没有必要做数据融合，纯粹的业务系统各自支持就好了。
第二，就算数据融合了，但它对业务的支撑不具备可复制性和可持续性，那也不必大动干戈就建设中台了。还是金店和菜市场的例子，当我们花了很大力气去采集数据并把两者汇聚起来之后，发现在菜市场的大妈中确实有一批专门抢购黄金的人，但抢黄金这种事情只会发生在黄金大跌或股市大跌的时候，几年不遇，难以预测，因此无法多次、持续地产生业务价值，所以就像我们一开始说的，资源投入和对业务带来的价值产出是不对等的。
故事也讲了，观点也说了，最后总结一下核心所在，我觉得“数据中台”：
l 它不是一个产品；
l 它不是固化的；
l 它不只是数据平台加数据应用；
l 它不只是海量异构的数据仓库；
l 它既是集中的“一体”，又是分散的“多个”；
l 它能提供中心化的管理，又能提供去中心化的服务；
l 它既能符合企业核心的数据化发展目标，又能满足组织个体探索式的数据需求；
l 它应该是企业组织架构和技术体系相融合的有机结合体。
--END--